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This application claims the benefit of United States Provisional Patent 
Application Number 60/191.278, filed March 22. 2000, and is a continuation 
of United States Patent Application No. 09/627.523, filed June 28, 2000, 
(pending) the disclosures of each of which are incorporated herein by 
reference in their entirety. 

Technical Field 

The present invention relates to presence database services, and 
more particularly to the routing and processing of presence service related 
signaling messages in a communications network. 



Instant messaging (IM), as it is currently known within the 
communications industry, is an Internet technology that allows subscribers to 
send and receive text messages, voice messages and other data in near 
real-time. While IM started as a way to chat with friends, the technology has 
become an essential tool for many businesses, as it offers the convenience 
of e-mail and the immediacy of a phone call, as well as file transfers and 
voice messaging. 

Instant messaging is possible because the people sending and 
receiving messages remain constantly connected to their IM service. 
Recipients get messages as fast as the data can travel across the Internet. 
Conventional e-mail, on the other hand, is less immediate. E-mail 
technology sends messages to a server that stores the items until they are 
downloaded by the recipient's e-mail software. Many industry experts argue 
that it is the "instant" or near real-time communication characteristic that has 
made and will continue to make IM a mode of communication in the future. 



V. 
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At present, when a subscriber logs in to an IM service, the 
subscriber's software notifies a presence server or similar client based 
presence system that the subscriber is available to receive messages. Such 
a scenario is generally illustrated in Figure 1 . Once the subscriber is logged 
5 in or "registered," the subscriber can choose to send a message to another 
online user. From a network communication perspective, such a 
communication is accomplished via the sending of data packets containing 
address and user-type information to the intended recipient. Depending on 
which service is used, a server either directly relays the message to the 

10 recipient or facilitates a direct connection between the sender of a message 
and the recipient. In Figure 1, communication between IM clients 100 is 
facilitated by presence server 102. In order to communicate with other 
instant message clients, subscribers send registration messages to 
presence server 102. The registration messages may contain contact 

15 information for IM clients 102. A proposed presence protocol for performing 
registration and subscription services will be discussed in more detail below. 

IM services typically employ one of three means to move messages 
around: a centralized network, a peer-to-peer connection, or a combination 
of both. In a centralized setup, users are connected to each other through a 

20 series of data servers. Such servers effectively form a wide area network 
(WAN). Consequently, when an instant message is sent by a subscriber, at 
least one of the data servers finds the intended recipient's PC address and 
routes the message through the network until it reaches its destination. 



25 of online subscribers and their associated Internet Protocol addresses. After 
a subscriber logs in, such a server sends the subscriber the IP addresses of 
everyone on their contact list who is also cunrently logged on. 

When a subscriber wishes to send an instant message to another 
user, the subscriber's client sends the IM directly to the user's client, without 

30 involving the server. As such, all IM message traffic does not necessarily go 
through the entire network. Such an architecture tends to result in improved 
network performance, as compared to other IM schemes. . 



In the peer-to-peer approach, a central server maintains a database 
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An excellent discussion of a proposed presence protocol can be 
found in an Internet Engineering Task Force (IETF) Internet Draft entitled, 
"The Presence Protocol," internet-draft-saraswat-presenceprotocol-OO.txt, 
February 26, 1999. the disclosure of which is incorporated herein by 
5 reference in its entirety. In the proposed presence protocol specification, a 
presence server is defined as a server that manages presence information 
for a collection of entities, subscriptions to those entities, and their privacy 
restrictions. 

Each server has an address at which presence messages may be 

10 delivered. Presence information is defined in the proposed presence server 
protocol specification as information such as presence status, current point- 
of presence (if any), idle time, etc., for an entity. As used herein, the term 
presence information refers to any information regarding an end user or 
entity, including, but not limited to: end user location, end user status, media 

15 capabilities of a telephony gateway associated with the end user, end user 
directory number, end user IP address, etc. 

An entity has control over publication of its presence information. An 
entity is defined as the unit, e.g. a person, on whose behalf presence 
information is being maintained. Each entity has a unique handle. The 

20 identity of the presence server maintaining presence information for the 
entity can be determined from the handle. A handle is well known name for 
an entity. An example of a handle is pp://www.intercom.sltt.com/TyrantRana. 
Finally, a point of presence (PoP) is defined as a point oif presence for an 
entity. If an entity is present, it is connected to one PoP. Each PoP has an 

25 address, e.g.. an IP address and a port number, at which presence 
messages may be delivered. 

A typical example of how the presence protocol may be used Is as 
follows. An entity A connected to an endpoint E may subscribed through a 
presence server P to another entity B. When the status of B changes, P will 

30 notify E of the change in status of B. if B's privacy specifications allow. If P 
is unable to notify E, for instance, because E is unreachable, P marks E as 
absent and will subsequently not attempt to deliver to E until E reestablishes 
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its presence. In addition, P may periodically ping an endpoint for current 
status information on the entities connected through that endpoint. Such a 
heartbeat from the presence sen/er ensures that presence information 
stored at the server is current. 
5 Once presence information about an entity is delivered to an 

endpoint, the endpoint may directly contact the entity. Protocols for 
exchanging instant messages, file transfer, etc. between two such endpoints 
are not defined in the above-referenced presence protocol specification. 
Similarly, the protocol used for communication between clients and PoPs is 
10 outside the scope of the presence protocol specification. In addition, the 
transport protocol used to deliver presence messages including presence 
registration and update messages is not defined in the presence protocol 
specification. 

One thing that the presence protocol specification does specify is 

15 message types used to perform presence-related actions. It is these 
message types that may be sent by a presence server to update and obtain 
presence information from a presence database. The message types 
include an assert message, which is sent by a PoP whenever the presence 
information associated with an entity changes. A fetch message is a request 

20 sent to the presence server to obtain presence infomnation regarding a target 
specified in the fetch message. A subscribe message is a message sent to 
the presence server to allow the subscriber to receive presence information 
updates regarding a target specified in the subscribe message. A notify 
message is a message sent by the presence server to a requestor or a 

25 subscriber to convey presence information about a named entity. 

There are cun^ently models, including the models described above, 
that provide for instant messaging (IM) and presence services within the 
scope of an Internet Protocol / data network environment. It will be 
appreciated from the discussion above that one of the key elements of IM 

30 operation involves the ability for one subscriber to "know" when another 
subscriber is logged in or is "available." From the discussion above, it will 
also be appreciated that the ability to track the login status, othenvise known 
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as "presence," of Internet users is fairly well developed and widely practiced. 
However, as communication networking technology has continued to evolve 
at a rapid pace, so have the means by which end users or subscribers can 
communicate. IVIore particularly, the explosive growth of hand-held, 
5 wireless communication terminals, such as cell phones, wireless WEB 
phones, and personal digital assistants has led to a demand for inter- 
networking or inter-medium communication solutions. In other words, it is 
rapidly becoming useful for a subscriber to have their wireless phone status 
or "presence" known to other subscribers, where these other subscribers 
10 may be using a variety of communication mediums, such as wireless phone 
service, wired phone service, short message service (SMS), or Internet 
service. 

At present, such data network-based presence models do not 
address the implementation of these services within a traditional Public 

15 Switched Telephone Network (PSTN) environment. Again, with the 
continuing movement towards the convergence of data and telephony 
networks, there exists the need to provide a system and method of enabling 
instant messaging and presence services in a communications environment 
that includes components of both traditional data and traditional telephony 

20 networks. Therefore, what is needed is an Instant messaging / presence 
model for use in a converged data and telephony network':. 

Disclosure of the Invention 
According to one aspect, the present invention Includes a presence 

25 registration and routing node. The presence registration and routing node 
receives a signaling system 7 (SS7) message in response to a telephony- 
related action, such as the activation of a mobile handset, the dialing of a 
directory number to establish a call, or the entry of predetermined DTMF 
digits. In response to the SS7 message, the presence registration and 

30 routing node formulates a presence-server-compatible message for updating 
presence information regarding an end user in a presence server database. 
The presence-server-compatible message may be in any presence-server- 
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compatible format, including session initiation protocol (SIP), presence, and 
Instant messaging and presence protocol (IMPP). SIP is defined in RFC 
2543. SIP: Session Initiation Protocol (March 1999). the disclosure of which 
is incorporated herein by reference In its entirety. IMPP is defined in RFC 
2778, A Model for Instant Messaging, (February 2000) and in RFC 2779: 
Instant Messaging / Presence Protocol Requirements (February 2000), the 
disclosures of each of which are incorporated herein by reference in their 
entirety. Presence is defined in a variety of documents, including the IETF 
Internet draft mentioned above and other IETF documents that will be 
discussed below. The present invention is not intended to be limited to any 
specific presence protocol format. The formats discussed herein are 
examples of presence protocol formats suitable for use with the present 
invention. 

According to another aspect, a presence registration and routing node 
includes an advanced database communications module (ADCM) for 
receiving queries for presence information. The ADCM module fonA/ards the 
queries to a presence application, such as a SIP, IMPP, or presence 
application. The presence application formulates a presence-server- 
compatible message, fonA^ards the presence-server-compatible message to 
a presence database, receives a response from the database, and fonvards 
the response to the ADCM module to be sent to the requestor over an IP 
network. The presence database may be internal or external to the 
presence registration and routing node. 

Some aspects of the invention will be explained in terms of modules 
and processes. It is understood that these modules or processes may be 
implemented in hardware, software, or a combination of hardware and 
software. Exemplary hardware upon which the processes and modules 
described below may execute includes a microprocessor, such as an Intel 
Pentium® processor and associated memory. Each of the modules in a 
presence registration and routing node according to the present invention 
may be a printed circuit board with a microprocessor and memory located 
thereon. The microprocessor may execute one or more computer programs 
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for performing the presence registration and routing functions discussed 
below. 

Accordingly, it is an object of the present invention to provide a 
presence registration and routing node for receiving SS7 messages in 
5 response to telephony-related actions and formulating presence-server- 
compatible messages in response to the SS7 messages. 

It is another object of the present invention to provide a presence 
registration and routing node for receiving Internet Protocol (IP) 
encapsulated SS7 messages in response to telephony-related actions and 
10 formulating presence-sen/er-compatible messages in response to the SS7 
messages. 

It is another object of the present invention to provide a presence 
registration and routing node capable of routing presencerserver-compatible 
messages to a presence database and forwarding responses from the 
1 5 database over an IP network. 

It is another object of the present invention to provide a presence 
registration and routing node that includes an internal or integrated presence 
database. 

It is another object of the present invention to provide a presence 
20 registration and routing node that is adapted to maintain accounting or billing 
information related to presence database access. 

Brief Description of the Drawings 
Preferred embodiments of the invention will now be explained with 
25 reference to the accompanying drawings of which: 

Figure 1 is a block diagram illustrating conventional presence and 
instant messaging message flow; 

Figure 2 is a block diagram of an SS7/IP gateway that may be 
modified to perfonm presence message processing according to 
30 embodiments of the present invention; 

Figure 3 is a block diagram of a presence registration and routing 
node according to an embodiment of the present invention; 
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Figure 4 is a block diagram of a presence registration and routing 
node according to an embodiment of the present invention; 

Figures 5a and 5b are a flow chart illustrating exemplary steps that 
may be performed by a presence registration and routing node in processing 
5 an lAM message according to an embodiment of the present invention; 

Figure 6 is a block diagram illustrating SCCP encapsulation of an 
ISUP lAM message; 

Figure 7 is a flow chart illustrating exemplary steps that may be 
performed by a presence registration and routing node in processing a 
10 TCAP message according to an embodiment of the present invention; 

Figure 8 is a block diagram illustrating the operation of a presence 
registration and routing node in a mobile telecommunications network 
according to an embodiment of the present invention; 



15 registration and routing node in processing an lAM message according to an 

embodiment of the present invention; 

Figure 10 is a block diagram illustrating the operation of a presence 

registration and routing node for in processing a TCAP message according 

to an embodiment of the present invention; 
20 Figure 11 is a block diagram of a presence registration and routing 

node including an internal presence database according to an embodiment 

of the present invention; 

Figure 12 is a flow chart illustrating exemplary steps that may be 

performed by the presence registration and routing node illustrated in Figure 
25 1 1 in responding to a presence query for updating presence information 

according to an embodiment of the present invention; 

Figure 13 Is a block diagram of a presence registration and routing 

node Including an external presence database according to an embodiment 

of the present invention. 
30 Figure 14 is a block diagram of a presence registration and routing 

according to an embodiment of the present invention that includes a 

message accounting and billing subsystem; 



Figure 9 is a block diagram illustrating the operation of a presence 
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Figure 15 is a table that illustrates a sample usage and 
measurements database associated with a message accounting and billing 
subsystem of the present invention; and 

Figure 16 is a block diagram of a presence registration and routing 
5 according to an embodiment of the present invention that includes a 
presence database and message accounting and billing subsystem. 



10 (PRR) node for communicating with and routing messages between both 
Internet Protocol (IP) and Signaling System 7 (SS7) network nodes. In one 
embodiment, a PRR node employs an internal architecture similar to that of 
high performance STP and signaling gateway (SG) prbducts which are 
marketed by Tekelec, Inc.. of Calabasas, California as the Eagle® STP and 

15 IP^ Secure Gateway*"^, respectively. A block diagram that generally 
illustrates the base internal architecture of the Eagle® STP product is shown 
in Figure 2. A detailed description of the Eagle® STP may be found in the 
Eagle® Feature Guide PN/91 0-1 225-01, Rev. B, January 1998. published by 
Tekelec. the disclosure of which is incorporated herein by reference in its 

20 entirety. Similarly, a detailed description of the IP^ Secure Gateway^ may 
be found in Tekelec publication PN/909-0767-01 , Rev B, August 1999. 
entitled Feature Notice IP^ Secure Gatewa/^ Release 10, the disclosure of 
which Is incorporated herein by reference in its entirety. The specific 
functional components of an IP^ Secure Gateway^ for transmitting and 

25 receiving TCAP messages over an Internet Protocol (IP) network are 
described in commonly-assigned, co-pending International Patent 
Publication No. WO 00/35155, Published June 15. 2000, the disclosure of 
which is incorporated herein by reference in its entirety. As described in the 
above referenced Eagle® Feature Guide, an Eagle® STP 250 includes the 

30 following subsystems: a IVIaintenance and Administration Subsystem (MAS) 
252. a communication subsystem 254 and an application subsystem 256. 



Detailed Description of the Invention 
The present invention includes a presence registration and routing 
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MAS 252 provides maintenance communications, initial program load, 
peripheral services, alarm processing and system disks. Communication 
subsystem 254 includes an Interprocessor Message Transport (IMT) bus 
that is the main communication bus among all subsystems in the Eagle® 
5 STP 250. This high-speed communications system functions as two 125 
Mbps counter-rotating serial buses. 

Application subsystem 256 includes application cards that are 
capable of communicating with the other cards through the IMT buses. 
Numerous types of application cards can be incorporated into STP 250, 

10 including: a Link Interface Module (LIM) 258 that provides SS7 links and 
X.25 links and an Application Service Module (ASM) 262 that provides global 
title translation, gateway screening and other services. A Translation 
Service Module (TSM) 264 may also be provided to support triggered local 
number portability service. Once again, a detailed description of the Eagle® 

15 STP is provided in the above cited Eagle® Feature Guide an6 need not be 
described in detail herein. With particular regard to the signaling gateway 
(SG) product line produced by Tekelec, it should also be appreciated that a 
Data Communication Module (DCM) 260 can be employed to provide for the 
transport of Internet Protocol (IP) encapsulated SS7 messages over an IP 

20 network, as described in the above referenced Feature Notice IP^ Secure 
Gateway^ Release 1,0 publication. With further regard to the TSM triggered 
LNP services module mentioned above, a detailed description of the Tekelec 
triggered LNP solution may be found in the Feature Guide LNP LSMS 
PN/91 0-1 598-01. Rev. A, January 1998. published by Tekelec. the 

25 disclosure of which is hereby incorporated herein by reference. 
Furthemnore, systems and methods for providing^^^ triggerless LNP 
functionality within a network routing node are described in commonly- 
assigned, co-pending U.S. Patent Application No. 09/503.541, filed Febmary 
14, 2000, the disclosure of which is incorporated herein by reference in its 

30 entirety. 
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SS7 MSU Triggered Presence Registration Message Generation 

Shown in Figure 3 is a schematic diagram of a presence registration 
and routing node 300 of the present invention. It will be appreciated that 
presence registration and routing node 300 includes a high speed 
Interprocessor Message Transport (IMT) communications bus 310. 
Communicatively coupled to IMT bus 310 are a number of distributed 
processing modules or cards including: a pair of Maintenance and 
Administration Subsystem Processors (MASPs) 312, an SS7-capable Link 
Interface Module (LIM) 320, an IP-capable Advanced Data Communication 
Module (ADCM) 360, and a Presence Registration Module (PRM) 340, 
These modules are physically connected to the IMT bus 310 such that 
signaling and other type messages may be routed Internally between all 
active cards or modules. For simplicity of illustration, only a single LIM 320, 
ADCM 360. and PRM 340 are included in Figure 3. However, it should be 
appreciated that the distributed, multi-processor architecture of the presence 
registration and routing node 300 facilitates the deployment of multiple LIM, 
ADCM, PRM, and other cards, all of which could be simultaneously 
connected to the IMT bus 310. 

MASP pair 312 implements the maintenance and administration 
subsystem functions described above. As the MASP pair 312 are not 
particularly relevant to a discussion of the flexible routing attributes of the 
present invention, a detailed discussion of their function is not provided 
herein. For a comprehensive discussion of additional MASP operations and 
functionality, the above-referenced Tekelec publications can be consulted. 

Focusing now on LIM card functionality, it will be appreciated that LIM 
320 is comprised of a number of sub-component processes including, but 
not limited to; an SS7 MTP level 1 process 322. an SS7 MTP level 2 process 
324, an I/O buffer or queue 325. a gateway screening (GWS) process 326, a 
Presence Registration Request (PRR) stop action process 328. an SS7 MTP 
level 3 layer HMDC process 330, and an HMDT process 332. MTP level 1 
and 2 processes 322 and 324, respectively, provide the facilities necessary 
to send and receive digital data over a particular physical media / physical 
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interface, as well as to provide error detection / correction and sequenced 
delivery of all SS7 message packets. I/O queue 325 provides for temporary 
buffering of incoming and outgoing signaling message packets, GWS 
process 326 is responsible for examining the incoming signaling message 
5 and determining which, if any, of the provisioned stop actions are applicable. 
PRR stop action process 328 is responsible for making a copy of, and 
subsequently encapsulating, an incoming SS7 ISDN User Part (ISUP) lAM 
signaling message packet within an SS7 Signaling Connection Control Part 
(SCCP) formatted packet. It should be appreciated that PRR stop action 

10 process 328 could also be configured to simply encapsulate the original 
incoming SS7 ISUP lAM signaling message, without making a copy. MTP 
level 3 HMDC process 330 receives signaling messages from the lower 
processing layers and performs a discrimination function, effectively 
determining whether an incoming SS7 message packet, requires internal 

15 processing or is simply to be through switched. For instance, In the case of 
an SS7 TCAP message associated with presence registration or an SCCP 
encapsulated ISUP lAM message, HMDC process 330 would detemnine that 
the message should be internally routed for further processing. HMDT 
process 332 manages or directs the internal routing of SS7 message 

20 packets that require additional processing prior to final routing. Once again, 
it should be appreciated that a LIM card may contain more functional 
processes than those described above. The above discussion is limited to 
LIM functionality associated with the basic processing of in-bound signaling 
messages. 

25 As such, it will be appreciated that the three functional processes 

associated with an Advanced Data Communications Mddule (ADCM) 360 
shown in Figure 3 are simply those processes that are relevant to a 
discussion of out-bound ADCM operation in the examples of PS routing 
node operation disclosed herein. Furthennore, it will be appreciated that 

30 ADCM 360 Is similar in function to the DCM application module described 
above. In the case of ADCM 360, the message packets processed by the 
card need not be native SS7 type messages that have been encapsulated in 
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an IP packet. Instead, the ADCM 360 is capable of processing, transmitting, 
and receiving both native SS7 and native IP protocol messages. 

The processes explicitly shown on the out-bound ADCM 360 include 
an I/O queue 362 and IP level 1 and 2 processes 366 and'364, respectively. 
5 I/O queue 362 facilitates temporary buffering of incoming and outgoing 
signaling message packets, while IP addressing operations are performed 
by the IP level 1 and 2 processes 366 and 364, respectively. 

Once again, the description of LIM and ADCM sub-components 
provided in the above description is limited to those sub-components that are 

10 relevant to the sample implementation scenarios discussed herein. For a 
comprehensive discussion of additional LIM and ADCM-type operations and 
functionality, the above-referenced Tekelec publications can be consulted. 

In general, a PRM card includes the database and database control 
processes necessary to achieve the presence registration message 

15 generation and routing functionality of the present invention. The PRM 340 
shown in Figure 3 is comprised, in part, of an SCCP subsystem controller 
known as a Signaling Connection Routing Controller (SCRC) process 342. a 
Presence Registration Manager (PRMG) process 344. and a number of 
Presence Registration Applications generally indicated by the numeral 346. 

20 Included among the Presence Registration Applications is a session initiation 
protocol (SIP) registration application process 348 for generating SIP 
messages, forwarding the SIP messages to a presence server, and 
processing SIP messages received from the presence server. The fonnat 
for SIP messages is described in detail in the above-referenced RFC 2543, 

25 which defines the SIP protocol. In addition, the portion of a SIP message 
that carries the media capabilities information for an end user device is 
referred to as the session description protocol portion. The session 
description protocol is described in detail in RFC 2327,'^"SDP: Session 
Description Protocol," (April 1998), the disclosure of which is incorporated 

30 herein by reference in its entirety. 
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Presence protocol process 349 may also be included for 
communicating with a presence server using the messages described in the 
above-referenced presence protocol specification. 

Instant messaging and presence protocol (IMPP) process 351 may 
5 also be included for communicating with a presence server according to the 
IMPP protocol. The IMPP protocol is described in detail above and in one 
or more of the following IETF Internet Draft documents: 



<draft-ietf-impp-pidf-01.b(t>, March 10, 2000; and 
"Transport Protocol for Presence Information/ Instant 
Messaging," <draft-ietf-impp-pitp-mitp-01>, March 9, 2000, 
the disclosures of each of which are incorporated herein by reference in their 
15 entirety. 

The present invention is not limited to communicating with a presence 
server using SIP, IMPP, or presence protocols. Any protocol for 
communicating with a presence server is within the scope of the invention. 
SCRC process 342 is responsible for discrimination of signaling 

20 messages at the SCCP level, and for distributing the signaling messages to 
an appropriate higher processing level application or function. In the 
configuration shown in Figure 3, the next highest processing level is 
represented by the PRMG process 344. PRMG process 344 is responsible 
for determining how to process the incoming message packet. For instance, 

25 if the message packet contains an SCCP encapsulated ISUP lAM message, 
PRMG process 344 is configured to de-capsulate the original ISUP lAM 
message, and subsequently extract the appropriate information necessary 
for further processing from the de-capsulated message. However, if the 
incoming message were a TCAP formatted packet, no de-capsulation action 

30 would be required. In either case, PRMG process 344 is also charged with 
determining which of the provisioned presence registration applications is 
required for successful processing of a particular incoming signaling 



10 



"Message Information Data Format," <draft-ietf-impp-midf- 
01.txt>, January 19, 2000; 

"Presence Information Data Format for IMPP," 
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message packet. As will be appreciated from Figure 3, a number of 
presence registration applications may be simultaneously provisioned on a 
single PRMG card. These presence registration applications may be 
configured such that each application is capable of generating presence 
5 registration messages that are formatted in different protocols including, but 
not limited to, SIP, IMPP, and presence protocol. 

While any of the above-described presence registration applications 
may be provisioned on a single PRM card, SIP registration application 348 is 
used in the examples described herein to illustrate the functionality of the 

10 presence registration and routing node in updating presence information in a 
presence server database and obtaining presence information. SIP 
registration application 348 essentially contains the logic necessary to 
process the incoming SS7 message and construct th^ appropriate* SIP- 
fomnatted presence registration message. 

15 Shown in Figures 3 and 4 are system level diagrams of one 

embodiment of presence registration and routing node 300 of the present 
invention. Also indicated in both figures are general message flows 
associated with the processing of incoming SS7 signaling packets and the 
generation of outbound presence registration messages. More particularly, 

20 Figure 3 illustrates the message flow associated with an incoming SS7 ISUP 
lAM message, while Figure 4 indicates the message flow associated with an 
incoming SS7 TCAP message. A detailed flow chart of the major steps 
associated with one particular implementation of the SS7 triggered presence 
registration message generation process is presented in Figures 5a and 5b, 

25 and may be used in conjunction with the schematic diagram shown in Figure 
3 to better understand the ISUP lAM based presence registration message 
generation methodology. 

Referring to Figure 5a. in step ST1. an incoming ISUP lAM message 
is received at the inbound LIM module 320. In steps ST2 and ST3. the 

30 incoming ISUP lAM message is received and processed by the MTP Level 1 
and 2 processes 322 and 324, respectively. With MTP Level 1 and 2 
processing complete, the signaling message packet is temporarily buffered 
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in the I/O queue 325 before being passed up the stack to the MTP Level 3 
Gateway Screening (GWS) process 326. As indicated in step ST4, GWS 
process 326 examines the incoming ISUP lAM message and determines not 
only whether the message is to be allowed into the switch for further 
5 processing, but also which, if any, of the provisioned stop actions are 
applicable to the incoming message. In this example. GWS process 326 
examines the incoming ISUP lAM message and determines that the 
message is permitted to enter the switch. Furthermore, upon examination of 
the Originating Point Code (OPC), Destination Point Code (DPC) and 

10 Service Indicator Octet (SIO) fields contained in the MTP routing layer, it is 
determined that the message requires additional processing by the PRR 
stop action 328 (ST5). In steps ST6 PRR stop action process 328 receives 
the ISUP lAM message from GWS process 326 and determines that the 
incoming message is an ISUP type MSU. The PRR stop action process 328 

15 next checks the DPC of the incoming MSU. More specif icklly, the PRR stop 
action verifies that the DPC of the incoming MSU is a valid PC. PRR stop 
action 328 examines the incoming MSU to determine whether presence 
registration service is required. If the incoming MSU is identified as being an 
ISUP I AM type message, PRR stop action 328 encapsulates a copy of the 

20 ISUP lAM message within an SCCP formatted MSU. as indicated in step 
ST6. Such SCCP encapsulation is effectively achieved by adding essential 
SCCP message leading and trailing bit sequences to the base bit sequence 
that comprises the ISUP lAM MSU. as generally illustrated in Figure 6. 
Thus, an SCCP type encapsulated MSU is created which envelops or 

25 contains an ISUP type MSU. Subsequent to this encapsulation, the 
incoming message no longer appears or is treated as an ISUP lAM message 
within the presence registration and routing node 300, but Is instead 
processed internally as an SCCP type SS7 message. 



30 the original ISUP lAM MSU is then routed directly to HMDC process 330 
where normal ISUP MSU type routing is resumed. However, once again, it 
should be appreciated that the original ISUP lAM MSU could be SCCP 



Unless additional processing by an unrelated subsystem is required. 
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encapsulated and further processed instead of producing a copy of the ISUP 
IVISU. It should also be appreciated that failure of the incoming ISUP MSU 
to meet the criteria specified in step causes the original, non-encapsulated 
MSU to be routed directly to HMDC process 330 where normal ISUP MSU 
5 type routing is resumed. 

However, in the case where an incoming ISUP MSU satisfies the ST5 
criteria, SCCP encapsulation of the ISUP MSU occurs and the resulting 
encapsulated MSU is directed to HMDC process 330 (ST7), where SCCP 
type processing is perfomried. In the example shown in Figure 3, HMDC 

10 process 330 examines the message packet and determines that the DPC 
and Subsystem Number (SSN) of the SCCP packet is the PC of the 
presence registration and routing node. Consequently, further processing of 
the SCCP MSU within the routing node is assumed to be necessary, and the 
packet is passed to the HMDT process 332. The HMDT process 332 

15 examines the Service Indicator (SI) field of the encapsulated MSU, which 
indicates that the encapsulating packet is of an SCCP type. As such, HMDT 
process 332 places the encapsulated SCCP MSU on high speed IMT bus 
310 for transport to PRM 340 and subsequent presence registration service. 
Referring to Figure 5b, in step ST8, the encapsulated SCCP MSU is 

20 received and examined by SCRC process 342 that is resident on PRM 340. 
SCBC process 342 examines the message, detenmlhes that presence 
registration service is indicated, and forwards the encapsulated MSU to the 
PRMG process 344, as indicated by step ST9. In step ST10, PRMG 
process 344 extracts the ISUP lAM MSU from the SCCP envelope and 

25 determines that the ISUP MSU requires the generation of a SIP-fonnatted 
presence registration message (ST11). The ISUP lAM MSU is subsequently 
directed to SIP application 348 for further processing (ST12). SIP 
application 348 examines the ISUP lAM MSU and, using information 
contained within the MSU, generates a SIP-formatted presence registration 

30 message (ST1 3). 

With SIP processing complete, the SIP-formatted presence 
registration message Is passed to HMRT process 350. HMRT process 350 
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determines to which ADCM card the SIP registration message packet should 
be routed for subsequent outbound transmission (ST14). In this case, the 
HMRT process 350 detemiines that the desired outbound signaling link 
associated with the routing of the SIP registration message is located on 
5 ADCM 360. Consequently, the SIP message packet is internally routed 
across the IMT bus 310 to LIM 360, where it is received by the I/O queue 
process 362 (ST15). Eventually, the modified message packet is passed 
from the I/O queue 362 on to the IP Level 2 and Level 1 processes 364 and 
366, respectively (ST16). Once again, IP level 1 and 2 processes 366 and 

10 364, respectively, provide the facilities necessary to send and receive digital 
data over a particular physical media / physical interface, as well as to 
provide error detection / correction and sequenced delivery of all IP message 
packets transmitted into the IP network. As indicated in step ST17, the SIP- 
formatted presence registration message is then transmitted into an IP 

15 network for ultimate delivery to and use by a presence database system. 

It will be appreciated that the registration message generation 
methodology shown in Figure 4 is fundamentally similar to the process 
indicated in Figures 5a and 5b. The primary difference involves processing 
variations that result from the handling of SS7 ISUP versus SS7 TCAP type 

20 messages. Most notably, since a TCAP message is, in fact, also an SCCP 
message, there is no need to directly encapsulate or copy and encapsulate 
the incoming TCAP message. Instead the TCAP message is simply directed 
from the inbound LIM 320 to the associated PRM 340 via the high speed 
IMT Bus 310, in much the same manner as the SCCP encapsulated ISUP 

25 lAM described in detail above. As such, Figure 7 presents a flow chart of the 
major steps associated with the processing of a TCAP-type presence 
registration request message, which may be used in conjunction with the 
schematic diagram shown in Figure 4 to better understand the TCAP based 
presence registration message generation methodology. 

30 With particular regard to the scenario generally illustrated in Figure 4. 

an incoming TCAP-formatted presence registration request message is 
received at the inbound LIM module 320 (ST1}. Once again, in steps ST2 
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and ST3, the incoming TCAP message is received and processed by the 
MTP Level 1 and 2 processes 322 and 324. respectively. With MTP Level 1 
and 2 processing complete, the signaling message packet is temporarily 
buffered in the I/O queue 325 before being passed up the stack to the MTP 
5 Level 3 Gateway Screening (GWS) process 326. As Indicated in step ST4. 
GWS process 326 examines the incoming TCAP message and determines 
not only whether the message is to be allowed into the switch for further 
processing, but also which, if any, of the provisioned stop actions are 
applicable to the incoming message. In the scenario shown in Figure 4. 

10 GWS process 326 examines the incoming TCAP message and determines 
that the message is permitted to enter the switchf Furthermore, upon 
examination of the Originating Point Code (OPC). Destination Point Code 
(DPC) and Service Indicator Octet (SIO) fields contained in the MTP routing 
layer, it is determined that the message does not require additional 

15 processing by the PRR stop action 328. As such, the TCAP MSU is then 
routed directly to HMDC process 330 where SCCP type processing is 
performed (ST5). In the example shown In Figure 4, HMDC process 330 
examines the message packet and detemiines that the DPC and Subsystem 
Number (SSN) of the TCAP packet is the PC of the presence registration 

20 and routing node. Consequently, further processing of the TCAP MSU 
within the routing node is assumed to be necessary, and the packet is 
passed to the HMDT process 332. The HMDT process 332 examines the 
Service Indicator (SI) field of the TCAP MSU, which indicates that the packet 
is of an SCCP type. As such, HMDT process 332 places the TCAP MSU on 

25 high speed IMT bus 310 for transport to PRM 340 and subsequent presence 
registration service. 

In step ST6, the TCAP MSU is received and examined by SCRC 
process 342 that is resident on PRM 340. SCRC process 342 examines the 
message, determines that presence registration service is indicated, and 

30 fonA^ards the TCAP MSU to the PRMG process 344, As indicated in step 
ST7. the content of the TCAP message is examined to determine whether 
the TCAP presence registration request requires the generation of a SIP- 
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formatted message. In this example, it Is assumed that the TCAP 
registration request message requires a SIP-formatted response and as 
such, is subsequently directed to SIP application 348 for further processing. 
SIP application 348 examines the TCAP MSU and. using information 
5 contained within the MSU. generates a SIP-formatted presence registration 
message (ST8). 

With SIP processing complete, the SIP-formatted presence 
registration message is passed to HMRT process 350. Ht^RJ process 350 
determines to which ADCM card the SIP registration message packet should 

10 be routed for subsequent outbound transmission (ST9). In this case, the 
HMRT process 350 determines that the desired outbound signaling link 
associated with the routing of the SIP registration message is located on 
ADCM 360. Consequently, the SIP message packet is internally routed 
across the IMT bus 310 to LIM 360, where it is received by the I/O queue 

15 process 362 (ST10). Eventually, the modified message packet is passed 
from the I/O queue 362 on to the IP Level 2 and Level 1 processes 364 and 
366, respectively (ST11). As indicated in step ST12, the SIP-formatted 
presence registration message is then transmitted into an IP network for 
ultimate delivery to and use by a presence database systern. 

20 Shown in Figures 8, 9 and 10 are simplified network diagrams that 

illustrate example implementations of the embodiments described above. 
More particularly. Figure 8 illustrates an implementation of the presence 
registration and routing node 300 of the present invention in a mobile or 
wireless telecommunications environment, generally indicated by the 

25 numeral 400. Network 400 includes a mobile subscriber 402. a base station 
complex 404, a mobile switching center (MSG) 406, a home location register 
(HLR) 408, and a presence server 410. It will be appreciated that the 
message flows shown in Figure 8 indicate that the presence registration and 
routing node 300 formulates and transmits a presence registration message 

30 416 in response to the receipt of a location update message 412 that is sent 
from the MSC 406. Those skilled in the art of wireless telecommunications 
will appreciate that an MSC performs a number of functions in a wireless 
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network, including the formulation and routing of signaling nnessages. In the 
example shown in Figure 8, the location update signaling message used by 
the presence registration and routing node 300 to trigger the presence 
registration message 416 is destined for the HLR node 408. In such a 
5 wireless scenario, the presence registration message 416 could be 
formulated and transmitted by the presence registration and routing node in 
response to a mobile location update message associated with the 
registration of a wireless customer in a particular cell or service area. Once 
again, those skilled in the art of wireless or mobile telecommunications will 

10 appreciate that wireless or mobile signaling messages are generated and 
transmitted within a wireless network in response to the powering-up or 
turning-on of a customer's wireless phone, as well as in response to inter- 
cell movement of a mobile subscriber during the course of a mobile call. As 
such, the presence registration and routing node of the present invention 

15 facilitates a method of presence registration that is completely transparent to 
the cell or mobile phone user. 

Figure 9 illustrates an implementation of the presence registration and 
routing node 300 of the present invention in a wired telecommunications 
environment, generally indicated by the numeral 420. Network 420 includes 

20 a wireline subscriber 422, an end office (EO) 424. and a presence server 
426. It will be appreciated that the message flows shown ih Figure 9 indicate 
that the presence registration and routing node 300 formulates and transmits 
a presence registration message 434 in response to the receipt of an ISUP 
call signaling message from the EO 424. More particularly, the presence 

25 registration message 434 is generated in response to the receipt of an ISUP 
Initial Address Message (lAM) message 428. Those skilled in the art SS7 
signaling will appreciate that an ISUP lAM message is the first in a sequence 
of ISUP formatted SS7 call control signaling messages that are required to 
complete a phone call in the Public Switched Telephone Network (PSTN). 

30 As such, it will be appreciated that in the scenario illustrated in Figure 9, the 
presence registration message 434 is formulated in response to an attempt 
by the wireline subsaiber 422 to place a telephone call. As presence 
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registration message generation is triggered by an ISUP lAM message, it will 
be appreciated by those skilled in the art of SS7 telecommunications that 
completion of an attempted telephone call is not required in order for a 
presence registration message to be generated and transmitted to a 
5 presence server. Thus, any call attempts by wireline subscriber 422 will 
effectively register the subscriber's presence with presence server 426 via 
presence registration and routing node 300 of the present invention. It will 
also be appreciated from Figure 9, that the triggering ISUP lAM message 
428 is subsequently routed as normal, on to a destination address specified 

10 in the message. 

Shown in Figure 10 is a variation of the scenario that was illustrated in 
Figure 9 whereby an SS7 signaling message used to trigger the formulation 
and subsequent transmission of a presence registration message is 
comprised of a TCAP-type message instead of an ISUP-type message. 

15 Shown in Figure 10 is an implementation of the presence registration and 
routing node 300 of the present invention in a wired telecommunications 
environment, generally indicated by reference numeral 440. Network 440 
includes a wireline subscriber 442, an end office (EO) 444. and a presence 
server 446. In the particular embodiment shown in Figure 10, it is assumed 

20 that wireline subscriber 442 indirectly initiates a TCAP message 448 by 
dialing "*88" or a similar code on a telephone keypad. Once again, those 
skilled in the art of SS7 telecommunication networks will appreciate that 
generation of such TCAP messages Is accomplished by an End Office (EO) 
or Service Switching Point (SSP) in response to the *'*88" keystrokes, as 

25 generally indicated in Figure 10. As such, by dialing "*88" wireline 
subscriber 442 is effectively manually registering their presence with the 
presence server via the generation of the TCAP message 448. which in turn 
causes the generation of a presence registration message 450 by the 
presence registration and routing node 300 of the present invention. 



30 
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Integrated Presence Database System 
The embodiments of the present invention described in detail above 
can be easily extended to include a presence registration and routing node 
that is capable of maintaining a presence database system. One 
5 embodiment of such a presence registration and routing node is illustrated in 
Figure 1 1 . and generally indicated by the numeral 500. It will be appreciated 
that in the particular embodiment presently contemplated, presence 
registration messages are not formulated and routed from the node, but 
instead presence registration takes place at or within the node. That is, in 

10 the embodiment of the present invention shown in Figure 11 and generally 
discussed below, the functionality of a presence server is generally included 
within the presence registration and routing node 500. 

With particular regard to the embodiment illustrated in Figure 1 1 and 
in a manner similar to the embodiment described above, it will be 

15 appreciated that presence registration and routing node 500 includes a high 
speed Interprocessor Message Transport (IMT) communications bus 310. 
Communicatively coupled to IMT bus 310 are a number of distributed 
processing modules or cards including: a pair of Maintenance and 
Administration Subsystem Processors (MASPs) 312, an SS7 capable Link 

20 Interface Module (LIM) 320, an IP capable Advanced Data Communication 
Module (ADCM) 360, and a Presence Database Module (PDM) 502. These 
modules are physically connected to the IMT bus 310 such that signaling 
and other type messages may be routed internally between all active cards 
or modules. For simplicity of illustration, only a single LIM 320. ADCM 360, 

25 and PDM 502 are included in Figure 1 1 . However, it should be appreciated 
that the distributed, multi-processor architecture of the presence registration 
and routing node 500 facilitates the deployment of multiple LIM. ADCM, 
PDM. and other cards, all of which could be simultaneously connected to the 
IMT bus 310. 

30 As in the previously described embodiment, MASP pair 312 

implement the overall maintenance and administration subsystem functions. 
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For a comprehensive discussion of additional MASP operations and 
functionality, the above-referenced Tekelec publications can be consulted. 

Once again, it will be appreciated that LIM 320 is comprised of a 
number of sub-component processes including, but not limited to: an SS7 
5 MTP level 1 process 322, an SS7 MTP level 2 process 324. an I/O buffer or 
queue 325, a gateway screening (GWS) process 326. a Presence Server 
Request (PRR) stop action process 328, an SS7 MTP level 3 layer HMDC 
process 330, and an HMDT process 332. MTP level 1 and 2 processes 322 
and 324, respectively, provide the facilities necessary to send and receive 

10 digital data over a particular physical media / physical interface, as well as to 
provide error detection / correction and sequenced delivery of all SS7 
message packets. I/O queue 325 provides for temporary buffering of 
incoming and outgoing signaling message packets. GWS process 326 is 
responsible for examining the incoming signaling message and determining 

15 which, if any, of the provisioned stop actions are applicable. PRR stop 
action process 328 is responsible for making a copy of, and subsequently 
encapsulating, an incoming SS7 ISDN User Part (ISUP) lAM signaling 
message packet within an SS7 Signaling Connection Control Part (SCCP) 
formatted packet. It should be appreciated that PRR stop action process 

20 328 could also be configured to simply encapsulate the original incoming 
SS7 ISUP lAM signaling message, without making a copy. MTP level 3 
HMDC process 330 receives signaling messages from the lower processing 
layers and performs a discrimination function, effectively determining 
whether an incoming SS7 message packet requires internal processing or is 

25 simply to be through switched. For instance, in the case of an SS7 TCAP 
message associated with presence registration or an SCCP encapsulated 
ISUP lAM message, HMDC process 330 would determine that the message 
should be internally routed for further processing. HMDT process 332 
manages or directs the internal routing of SS7 message packets that require 

30 additional processing prior to final routing. Once again, it should be 
appreciated that a LIM card may contain more functional processes than 
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those described above. The above discussion is limited to LIM functionality 
associated with the basic processing of in-bound signaling messages. 

As such, it will be appreciated that the three functional processes 
associated with Advanced Data Communication Module (ADCM) 360 shown 
5 in Figure 1 1 are simply those processes that are relevant to a discussion of 
outbound ADCM operation in the examples of PS routing node operation 
disclosed herein. Furthermore, it will be appreciated that ADCM 360 is 
similar in function to the DCM application module described above. In the 
case of ADCM 360, the message packets processed by the card need not 

10 be native SS7 type messages that have been encapsulated in an IP packet. 
Instead, the ADCM 360 is capable of processing, transmitting, and receiving 
both native SS7 and native IP protocol messages. 

The processes explicitly shown on the out-bound ADCM 360 include 
an I/O queue 362 and IP level 1 and 2 processes 366 and 364. respectively. 

15 I/O queue 362 facilitates temporary buffering of incoming and outgoing 
signaling message packets, while IP addressing operations are performed 
by IP level 1 and 2 processes 366 and 364, respectively. 

Once again, the description of LIM and ADCM sub-components 
provided in the above description is limited to those sub-components that are 

20 relevant to the sample Implementation scenarios discussed herein. For a 
comprehensive discussion of additional LIM and ADCM-type operations and 
functionality, the above-referenced Tekelec publications can be consulted. 

In general, a PDM card includes the database and database control 
processes necessary to facilitate the presence registration and query 

25 handling functionality of the contemplated embodiment of the present 
invention. The PDM 502 shown in Figure 11 Is comprised, in part, of an 
SCCP subsystem controller known as a Signaling Connection Routing 
Controller (SCRC) process 504. a Presence Database Manager (PDMG) 
process 510, and a number of Presence Database Interface (PDI) 

30 Applications generally indicated by reference numeral 512. Included among 
the PDI Applications 512 are session initiation protocol (SIP) application 
process 518, IMPP application process 514, and presence protocol process 
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519. SCRC process 504 is responsible for discrimination of signaling 
messages and subsequent distribution of these signaling messages to an 
appropriate higher processing level application or function. In the 
configuration shown in Figure 11, the next highest processing level is 
5 represented by PDMG process 510. PDMG process 510 is generally 
responsible for determining which of the provisioned protocol-specific PDI 
Applications 512 is required process the incoming message packet. For 
instance, if the incoming presence registration packet contained a TCAP or 
SCCP-encapsulated IMPP message, PDMG process 510 would determine 

10 that the provisioned PDI application 514 was required for successful 
processing. As will be appreciated from Figure 11, a number of PDI 
applications 512 may be simultaneously provisioned on a single PDMG card. 
These protocol-specific PDI applications may be configured such that each 
application is capable of receiving presence registration or query messages 

15 that are fonnatted in different protocols including, but not limited to, SIP, 
IMPP, and the presence protocol. Furthermore, these PDI applications 512 
are also capable of generating or formatting protocol-specific presence 
service related response messages. Such a presence service response 
message might Include, but is not limited to, a message that provides 

20 presence status information for a specific user in response to a presence 
status query. This particular scenario is specifically illustrated in Figure 11, 
where the presence status query packet assumes the form of an SS7 TCAP- 
encapsulated IMPP query message and the subsequent presence status 
response is contained within a SIP formatted message. 

25 Once again, while any number or variety of PDI ap'pllcations may be 

provisioned on a single PDM card, only the IMPP, SIP, and presence 
protocol PDI applications 514, 518, and 519, respectively, are described 
herein. SIP PDI application 518 essentially contains the logic necessary to 
process incoming SIP presence messages and construct outgoing SIP 

30 presence response messages. Similarly. IMPP PDI application 514 contains 
the logic necessary to process incoming IMPP formatted presence 
messages and construct outgoing IMPP formatted presence response 
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messages. Presence PDl application 519 contains the logic necessary to 
process incoming presence query messages formatted according to the 
presence protocol and construct outgoing presence response messages 
formatted according to the presence protocol. 
5 Also included in Figure 1 1 is a general message flow associated with 

the processing of an incoming SS7 TCAP-encapsulated IMPP formatted 
presence query message and the subsequent, related presence system 
processing activity. A detailed flow chart of the major steps associated with 
a TCAP-encapsulated IMPP presence query scenario is presented in Figure 
10 12, and may be used in conjunction with the schematic diagram shown in 
Figure 1 1 to better understand the operation of presence registration and 
routing node 500. 

With particular regard to the scenario generally illustrated in Figure 
11, it is assumed that an incoming TCAP-encapsulated IMPP formatted 

15 presence query message is received at the inbound LIM rriodule 320 (ST1). 
Once again, in steps ST2 and ST3, the incoming TCAP-encapsulated IMPP 
formatted presence query message is received and processed by the MTP 
Level 1 and 2 processes 322 and 324, respectively. With MTP Level 1 and 2 
processing complete, the signaling message packet is temporarily buffered 

20 in the I/O queue 325 before being passed up the stack to MTP Level 3 
Gateway Screening (GWS) process 326. As indicated in step ST4, GWS 
process 326 examines the incoming TCAP presence query message and 
determines not only whether the message is to be allowed into the switch for 
further processing, but also which, if any, of the provisioned stop actions are 

25 applicable to the incoming message. In the scenario shown in Figure 1 1 . 
GWS process 326 examines the incoming TCAP-encapsulated IMPP 
presence query message and determines that the message is permitted to 
enter the switch. Furthermore, upon examination of the Originating Point 
Code (OPC), Destination Point Code (DPC) and Service Indicator Octet 

30 (SIO) fields contained in the MTP routing layer, it is determined that the 
message does not require additional processing by the PRR stop action 328. 
As such, the TCAP MSU is then routed directly to HMDC process 330 where 
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SCCP type processing is performed {ST5). In the example shown in Figure 
11, HMDC process 330 examines the message packet and determines that 
the DPC and Subsystem Number (SSN) of the TCAP packet is the PC and 
SSN of the internal presence server database system that is located on PDM 
5 card 502. Consequently, further processing of the TCAP MSU within the 
routing node is assumed to be necessary, and the packet is passed to the 
HMDT process 332. The HMDT process 332 examines the Service Indicator 
(SI) field of the TCAP MSU, which indicates that the packet is of an SCCP 
type. As such, HMDT process 332 places the TCAP MSU on high speed 
10 IMT bus 310 for transport to PDM 502 and subsequent presence database 
service. 

In step ST6, the TCAP MSU is received and examined by SCRC 
process 504 that is resident on PDM 502. SCRC process 504 examines the 
message, determines that presence database service is indicated, and 

15 forwards the TCAP MSU to the PDMG process 510. As indicated in step 
ST7, the message packet is examined to determine the protocol of the 
presence related message. In this case, the protocol of the' presence related 
message encapsulated within the TCAP packet is IMPP. Next in step ST8 
the variety or type of presence service associated with the message is 

20 evaluated. Such general presence message types or varieties might 
include, but are not limited to, query and registration type messages. 

Once again, in this example, the IMPP-formatted presence service 
message is a query message that is intended to extract information from a 
presence service database. As such, the IMPP formatted query message is 

25 directed to IMPP application 514 for further processing. IMPP application 
514 examines the message and, using infomiation contained within the 
packet, directs the query to presence database 516 (ST9). Presence 
database 516 processes the query and, in this example, returns the 
requested information to SIP application 518 for formatting of the out-bound 

30 response message (ST10). 

With the necessary SIP formatting complete, the SlP-formatted 
presence registration message is passed to an HMRT process 520. HMRT 
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process 520 determines to which ADCM card the SIP registration message 
packet should be routed for subsequent outbound transmission (ST11). In 
this case, the HMRT process 520 determines that the desired outbound 
signaling link associated with the routing of the SIP registration message is 
5 located on ADCM 360. Consequently, the SIP message packet is internally 
routed across the IMT bus 310 to LIM 360, where it is generally received by 
the I/O queue process 362 (ST12). Eventually, the modified message 
packet is passed from the I/O queue 362 on to the IP Level 2 and Level 1 
processes 364 and 366. respectively. As indicated in step ST13. the SIP- 

10 formatted presence registration message is then transrhitted into an IP 
network for ultimate delivery to and use by a presence database system. 

It will be appreciated from Figure 12, that if the IMPP-formatted 
presence service message were a registration request-type message, then 
IMPP application 514 would examine the message and, using information 

15 contained within the packet, direct the registration request to presence 
database 516 (ST14). In such a scenario, a response or acknowledgment 
message may not necessarily be required. 

Externallv Mounted Presence Database Svstem 
20 The embodiments of the present invention described in detail above 

can be easily extended to include a presence registration and routing node 
that incorporates an externally mounted presence database system or server 
platform. One embodiment of such a presence registration and routing node 
is illustrated in Figure 13, and generally indicated by the numeral 600. Once 
25 again, it will be appreciated that in the particular embodiment presently 
contemplated, presence registration messages are not formulated and 
routed from the node, but instead presence registration takes place at or 
within the node. 

With particular regard to the embodiment illustrated in Figure 13 and 
30 in a manner similar to the embodiment described above, it will be 
appreciated that presence registration and routing node 600 includes a high 
speed Interprocessor Message Transport (IMT) communications bus 310. 
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Communicatively coupled to IMT bus 310 are a number of distributed 
processing modules or cards including: a pair of Maintenance and 
Administration Subsystem Processors (MASPs) 312, an SS7 capable Link 
Interface Module (LIM) 320, an IP capable Advanced Data Communication 
5 Module (ADCM) 360, and an External Presence Database Module (EPDM) 
700. As further indicated in Figure 13, EPDM is connected to an external 
Presence Database Server platform 800 via a high-speed Ethernet-type 
connection 802. In this embodiment, external Presence Database Server 
platform 800 includes the actual Presence Database entity 516. With 

10 exception of the EPDM card 700 and external Presence Database Server 
800. all other functional and operational aspects of the embodiment shown 
in Figure 13 are identical to that of the embodiment shown in Figure 1 1 and 
generally described above. 

In general, an EPDM card 700 includes the database and database 

15 control processes necessary to facilitate the presence registration and query 
handling functionality of the contemplated embodiment of the present 
invention. The EPDM 700 shown in Figure 13 is comprised, in part, of an 
SCCP subsystem controller known as a Signaling Connection Routing 
Controller (SCRC) process 504, a Presence Database Manager (PDMG) 

20 process 510. and a number of Presence Database Interface (PDI) 
Applications generally indicated by the numeral 512. Included among the 
PDI Applications 512 are a session initiation protocol (SIP) application 
process 518, an IMPP application process 514, and a presence protocol 
process 519. The SCRC process 504 is responsible for discrimination of 

25 signaling messages and subsequent distribution of these signaling 
messages to an appropriate higher processing level application or function. 
In the configuration shown in Figure 13, the next highest processing level is 
represented by the PDMG process 510. PDMG process 510 is generally 
responsible for determining which of the provisioned protocol-specific PDI 

30 Applications 512 is required process the incoming message packet. The PDI 
applications 512 are capable of generating or formatting protocol-specific 
presence service related response messages. Such a presence service 
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response message might include, but is not limited to, a message that 
provides presence status information for a specific user in response to a 
presence status query. 

In the embodiment shown in Figure 13, EPDM card 700 further 
5 includes an Ethernet Controller (EC) process 702 which is communicatively 
coupled to the provisioned PDI applications 512 and also to the external 
Presence Database Server 800. More particularly, EC 702 is coupled to a 
corresponding EC process 802 that resides on the external Presence 
Database Server 800. ECs 702 and 802 facilitate the communication of 
10 messages between the PDI applications 512 and the Presence Database 
516. In all other respects, operation of the presence registration and routing 
node is identical to that of presence registration and routing node 500 
described above and illustrated in Figure 11. 

15 Integrated Message Accounting And Billing Subsvstem 

Shown in Figure 14 is another embodiment of a presence registration 
and routing node of the present invention, generally indicated by the numeral 
900. With particular regard to the embodiment illustrated in Figure 14 and in 
a manner similar to the embodiment described above, it will be appreciated 

20 that presence registration and routing node 900 includes a high speed 
Interprocessor Message Transport (IMT) communications bus 310. As in the 
previously described embodiments, communicatively coupled to IMT bus 
310 are a number of distributed processing modules or cards including; a 
pair of Maintenance and Administration Subsystem Processors (MASPs), an 

25 SS7 capable Link Interface Module (LIM) 320, and an IP capable Advanced 
Data Communication Module (ADCM) 360, and a Presence Registration 
Module (PRM) 340. Further included in the presence registration and 
routing node 900 is an accounting and billing subsystem which is comprised 
of an accounting subsystem interface module (ASIM), generally indicated by 

30 the numeral 910. and an accounting server platfonm (ASP), generally 
indicated by the numeral 920. It will be appreciated that the combination of 
ASIM card 910 and ASP accounting server 920 includes the database and 
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control processes necessary to achieve the accounting and billing 
functionality of the present invention. From a practical innplementation 
standpoint, ASP 920 could assume the form of a Sun Workstation or similar 
type computing platform. It will be further appreciated that an entire 
5 message accounting subsystem could also be integrated within a presence 
routing and registration node. 

The ASIM card 910 shown in Figure 14 includes a Signaling 
Connection Control Part (SCOP) subsystem 912 that is responsible for 
receiving and preliminary processing of incoming SCCP encapsulated 

10 accounting message packets. ASIM card 910 also includes an SCCP 
controller known as a Signaling Connection Routing Controller (SCRC) 
process 914 and a high-speed Ethernet Controller (EC) process 916. Once 
again, as described above, the SCCP subsystem 912 is responsible for 
receiving and preliminary processing of incoming SCCP encapsulated 

15 message packets, while the SCRC process 914 is responsible for 
discrimination and subsequent distribution of messages based on 
information contained in an SCCP packet. In the case of ASIM card 910, 
messages that satisfy the SCRC discrimination criteria are distributed or 
directed to the high-speed Ethernet Controller process 916. EC process 916 

20 is in turn responsible for controlling the process of communicating 
messages, via an Ethernet connection to and from the associated ASP 
server 920. More particulariy, ASP server 920 includes a corresponding 
high-speed Ethernet Controller process 922 that serves as the 
communications interface between ASIM card 910 and an on-board 

25 accounting server manager (ASM) process 924. ASM process 924 is 
responsible for the de-capsulation or removal of the SCCP envelope that 
contains the accounting message. The de-capsulated accounting message 
is then passed to an adjacent usage and measurements process 926 where 
usage and measurement statistics are created and stored in a usage and 

30 measurements database (UMD) process 930, such as that shown in Figure 
15. 
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Usage and measurements statistics produced by such a process 
could include, but are not limited to, peg counts of messages received from a 
specific network address, a specific service provider, a specific service user, 
a specific IP socket, or a specific signaling link. Furthermore, information 
5 specific to the type of service requested, calling and called party information, 
and other information associated with a communication that could be useful 
in generating a bill or invoice may also be stored in a UMD. As shown in 
sample UMD process 930, in one simplified embodiment, each 
communication is identified by a transaction ID, and certain predetermined 
10 information associated with a communication can be stored in the database. 
It will be appreciated that the information contained in a UMD database 
could be significantly more or less detailed than that indicated in the example 
shown in Figure 15. 



15 the time-of-day that a message was received, the duration of a "call" or 
communication, general quality of service (QoS) indicators associated with a 
"call" or communication, information related to or identifying the type of 
service that is associated with a "cair or communication (i.e., broadband 
service related, call setup related, database query related, etc.). Such usage 

20 information could be used to bill a subscriber at different rates depending 
upon the type of service requested. With such capability included within a 
presence server and routing node, network operators greatly increased 
flexibility with regard to service-specific billing, without significantly 
Increasing network OA&M requirements. 

25 In order to facilitate such billing operations, ASP server 920 also 

includes a billing process 928 that is adapted to extract information stored by 
the usage and measurements process 926 and subsequently generate bills. 
Once again, information or parameters maintained by process 926 that may 
be used in the generation of bills could include, but is not limited to, a 

30 network address identifier, a service provider identifier, a service user 
identifier, an IP socket identifier, a signaling link identifier, and a service type 
identifier. It will be further appreciated that a network address identifier could 



In any event, such statistics could include information associated with 
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include, but is not limited to a destination or origination SS7 point code, a 
destination or origination IP address, and a destination or origination domain 
name. Similarly, a user identifier could include, but is not limited to a calling 
or called party telephone number, and a destination or origination email 
5 address. 

In the particular embodiment shown, LIM card 320 includes a 
Presence Registration Request (PRR) stop action process 902, that is 
functionally similar to the PRR process 328 described above. In addition to 
generate, and SCCP encapsulate an accounting message that is 

10 subsequently passed via IMT bus 310 to ASIM 910 of the accounting and 
billing subsystem. 

In a preferred embodiment, a normalized accounting message (NAM) 
format is employed to provide the necessary message infomnation content to 
the associated accounting and billing subsystem. That is, a NAM formatted 

15 accounting message employs a field or record structure that is essentially a 
superset of all parameters of interest from all signaling, presence and instant 
messaging protocols of interest. As such, parameters of interest in a SIP 
formatted signaling message can be easily accommodated in a NAM 
accounting message, as can parameters of interest in an SS7 formatted 

20 signaling message. It will be further appreciated that the NAM format can be 
periodically expanded (or revised) to accommodate new or evolving 
signaling protocols that must be supported by a presence registration and 
routing node of the present invention. LIM card 320 can also be configured 
to simply encapsulate a copy of the received signaling message packet and 

25 foHA^ard the packet to the associated accounting and billing subsystem. 

With regard to the message encapsulation discussed above. It should 
be appreciated that SCCP encapsulation of a NAM message Is not essential 
to the operation of the message accounting subsystem of the present 
invention. Other internal encapsulating protocols could be just as easily 

30 employed, provided that a suitably provisioned ASIM module is capable of 
receiving and processing the encapsulated messages. In fact, no 
encapsulation necessarily need be performed, so long as the accounting 
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message generated by a PRR type process can be received and generally 
processed by a suitable configured ASIM module. 

Figure 16 illustrates yet another embodiment of a presence 
registration and routing node of the present invention, which extends the 
5 integrated accounting and billing subsystem concept to the routing node 
previously presented in Figure 11. This new embodiment of a presence 
server and routing node is generally Indicated by the numeral 950. With 
particular regard to the embodiment illustrated in Figure 16 and in a manner 
similar to those embodiments described above, it will be appreciated that 

10 presence registration and routing node 950 includes a high speed 
Interprocessor Message Transport (IMT) communications bus 310. 
Communicatively coupled to IMT bus 310 are a number of distributed 
processing modules or cards including: a pair of Maintenance and 
Administration Subsystem Processors (MASPs), an SS7 capable Link 

15 Interface Module (LIM) 320, and an IP capable Advanced Data 
Communications Module (ADCM) 360, and a Presence Registration Module 
(PRM) 340. Further included in the presence registration and routing node 
950 is an accounting and billing subsystem which is comprised of an 
accounting subsystem interface module (ASIM), generally indicated by the 

20 numeral 910, and an accounting server platform (ASP), generally indicated 
by the numeral 920. Again, it will be appreciated that the combination of 
ASIM card 910 and ASP accounting server 920 includes the database and 
control processes necessary to achieve the accounting and billing 
functionality of the present invention. 

25 In the particular embodiment shown, LIM card 320 includes a 

Presence Registration Request (PRR) stop action process 952. that is 
functionally similar to the PRR process 902 described above. PRR 952 Is 
adapted to generate, and SCCP encapsulate, an accounting message that is 
subsequently passed via IMT bus 310 to ASIM 910 of the accounting and 

30 billing subsystem, where accounting and billing subsystem processing 
occurs in a manner similar to that described above. 
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It will be understood that various details of the invention may be 
changed without departing from the scope of the invention. Furthermore, the 
foregoing description is for the purpose of illustration only, and not for the 
purpose pf limitation — the invention being defined by the claims. 
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CLAIMS 

What is claimed is: 

A method for updating presence information regarding an end user in 
a presence server database based on information derived from a 
telephony-related action, the method comprising: 

(a) receiving a signaling system seven (SS7) message in 
response to a telephony-related action performed by an end 
user; 

(b) in response to receiving the SS7 message, formulating an 
internet protocol (IP) message for updating presence 
information regarding the end user managed by a presence 
server; and 

(c) transmitting the IP message to the presence server over an IP 
network. 

The method of claim 1 wherein the telephony-related action includes 
dialing a called party telephone number utilizing a PSTN telephone 
and the signaling system seven message is an lAM message. 
The method of claim 1 wherein the telephony-related action includes 
entering DTMF digits using a PSTN telephone handset after a call has 
been established, the DTMF digits forming a code for instructing an 
end office to formulate the SS7 message. 

The method of claim 3 wherein the SS7 message is a transaction 
capabilities application, part (TCAP) message containing presence 
information for the end user. 

The method of claim 1 wherein the telephony-related action is the 
activation of a mobile telephone handset and the SS7 message is a 
message for updating the status of the subscriber in at least one of a 
home location register (HLR) and a visitor location register (VLR). 
The method of claim 1 wherein formulating an IP message includes 
formulating a presence protocol message. 

The method of claim 1 wherein formulating an IP message includes 
formulating a session initiation protocol (SIP) message. 
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8. The method of claim 1 wherein formulating an IP imessage includes 
formulating an instant messaging and presence protocol (IMPP) 
message. 

9. The method of claim 1 comprising, in response to receiving the SS7 
5 message, sending a second message to an accounting and billing 

system. 

1 0. The method of claim 9 wherein the second message is a copy of the 
SS7 message. 

11. A method for processing a query to a presence server database, the 
10 method comprising: 

(a) receiving, at presence registration and routing node, an IP 
message for determining presence information for an entity; 

(b) formulating a query to a presence database* for obtaining the 
presence information; 

15 (c) obtaining the presence information from the presence 

database; and 

(d) forwarding the presence information to an end user. 

12. The method of claim 11 wherein receiving an IP message includes 
receiving a presence protocol message. 

20 13. The method of claim 12 wherein receiving a presence protocol 
message includes receiving a fetch message requesting presence 
information regarding the entity. 

14. The method of claim 11 wherein fonvarding the presence information 
to an end user includes forwarding a presence protocol message to 

25 the end user. 

15. The method of claim 14 wherein fon/varding a presence protocol 
message includes fonA^arding a notify message to the end user. 

16. The method of claim 11 wherein receiving an IP message includes 
receiving a session initiation, protocol (SIP) message. 

30 17. The method of claim 11 wherein receiving an IP message includes 
receiving an instant messaging and presence protocol (IMPP) 
message. 
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18. The method of claim 11 wherein obtaining the presence information 
from the presence database includes obtaining the presence 
information from a presence database located internal to the 
presence registration and routing node. 
5 19. The method of claim 11 wherein obtaining the presence information 
from the presence database includes obtaining the presence 
infomiation from a presence database located external to the 
presence registration and routing node. 

20. The method of claim 1 1 comprising, in response to receiving the IP 
10 message, sending a second message to an accounting and billing 

system. 

21 . The method of claim 20 wherein the second message is a copy of the 
IP message. 

22. A presence registration and routing node for updating presence 
15 information regarding an end user in a presence server database, the 

presence registration and routing node comprising: 

(a) a communication module for receiving an SS7 message from 
an SS7 network; and 

(b) a presence server message generator for generating a 
20 presence-server-compatible message for updating presence 
' information regarding an end user in a presence server 

database, based on the SS7 message. 

23. The presence registration and routing node of claim 22 comprising an 
advanced data communication module for encapsulating the 

25 presence-server-compatible message in an IP paclcet and transmitting 

the IP packet to a presence server over an IP network. 

24. The presence registration and routing node of claim 22 wherein the 
presence-server-compatible message is a session initiation protocol 
(SIP) message. 

30 25. The presence registration and routing node of claim 22 wherein the 
presence-server-compatible message is a presence protocol 
message. 
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26. The presence registration and routing node of claim 22 wherein the 
presence-server-compatible message is an instant messaging and 
presence protocol (IMPP) message. 

27. The presence registration and routing node of claim 22 wherein the 
5 SS7 message is an ISDN user part (ISUP) message. 

28. The presence registration and routing node of claim 22 wherein the 
SS7 message is a transaction capabilities application part (TCAP) 
message. 

29. The presence registration and routing node of claim 22 wherein the 
10 SS7 message is a message from a mobile switching center (MSG). 

30. The presence registration and routing node of claim 22 comprising a 
presence server database operatively associated with the presence 
server message generator for receiving the presence-server- 
compatible message and for extracting the presence information in 

1 5 response to the presence-server compatible message. 

31. The presence registration and routing node of claim 30 wherein the 
presence server database is located internal to the presence 
registration and routing node. 

32. The presence registration and routing node of claim 30 wherein the 
20 presence server database is located external to the presence 

registration and routing node. 

33. The presence registration and routing node of claim 22 wherein the 
presence server message generator is adapted to receive presence 
queries, forward the presence queries to a presence server database, 

25 and receive responses from the presence server database. 

34. The presence registration and routing node of claim- 22 comprising: 
(a) means for generating an accounting message based on at 

least one of the SS7 message received by the communication 
module and the presence-server-compatible message; and 
30 (b) an accounting and billing system for storing accounting 

information based on the accounting message. 
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35. A presence registration and routing node for providing presence 
information regarding an entity, the presence registration and routing 
node comprising: 

(a) an advanced data communication module for receiving an IP- 
5 encapsulated presence-server-compatible message for 

determining presence information for an entity; and 

(b) a presence server message processor for forwarding the 
presence-server-compatible message to a presence server for 
determining the presence information. 

10 36. The presence registration and routing node of claim 35 wherein the 
presence sen/er message processor is adapted to receive the 
presence Information from the presence server and forward the 
presence information to the advanced database communications 
module. 

15 37. The presence registration and routing node of claim 36 wherein the 
advanced database communications module is adapted to forward 
the presence information to an endpoint over an IP network. 

38. The presence registration and routing node of claim 35 comprising a 
presence server operatively associated with the presence server 

20 message processor for providing the presence infonmation to the 

presence server message processor. 

39. The presence registration and routing node of claim 38 wherein the 
presence server is located internal to the presence registration and 
routing node. 

25 40. The presence registration and routing node of claim 38 wherein the 
presence server is located external to the presence registration and 
routing node. 

41 . The presence registration and routing node of claim '35 comprising: 

(a) means for generating an accounting message based on the 
30 presence-server-compatible message; and 

(b) an accounting and billing system for storing accounting 
infonmation based on the accounting message. 
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42. A computer program product comprising computer-executable 
instructions embodied in a computer-readable medium for performing 
steps comprising: 

(a) receiving a signaling system seven (SS7) message in 
5 response to a telephony-related action performed by an end 

user; 

(b) in response to receiving the SS7 message, formulating an 
Internet protocol (IP) message for updating presence 
information regarding the end user managed by a presence 

10 server; and 

(c) transmitting the IP message to the presence server over an IP 
network. 

43. The computer program product of claim 42 wherein the telephony- 
related action includes dialing a called party telephone number 

15 utilizing a PSTN telephone and the signaling system seven message 

is an lAM message. 

44. The computer program product of claim 42 wherein the telephony- 
related action includes entering DTMF digits using a PSTN telephone 
handset after a call has been established, the DTMF digits forming a 

20 code for instructing an end office to formulate the SS7 message. 

45. The computer program product of claim 42 wherein the SS7 message 
is a transaction capabilities application part (TCAP) message 
containing presence infonnation for the end user. 

46. The computer program product of claim 42 wherein the telephony- 
25 related action is the activation of a mobile telephone handset and the 

SS7 message is a message for updating the status of the subscriber 
in at least one of a home location register (HLR) and a visitor location 
register (VLR). 

47. The computer program product of claim 42 whereiri formulating an IP 
30 message includes fonnulating a presence protocol message. 
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48. The computer program product of claim 42 wherein formulating an IP 
message includes formulating a session initiation protocol (SIP) 
message. 

49. The computer program product of claim 42 wherein formulating an IP 
5 message includes formulating an instant messaging and presence 

protocol (IMPP) message. 

50. The computer program product of claim 42 comprising generating an 
accounting message in response to at least one of the SS7 message 
and the IP message and fonvarding the accounting message to an 

. 10 accounting and billing subsystem. 

51. A computer program product comprising computer executable 
instructions embodied in a computer-readable medium for performing 
steps comprising: 

(a) receiving, at a presence registration and routing node, an IP 
15 message for determining presence information for an entity; 

(b) formulating a query to a presence database for obtaining the 
presence information; 

(c) obtaining the presence information from the presence 
database based on the query; and 

20 (d) fonvarding the presence information to an end user. 

52. The computer program product of claim 51 wherein receiving an IP 
message includes receiving a presence protocol message. 

53. The computer program product of claim 52 wherein receiving a 
presence protocol message includes receiving a fetch message 

25 requesting presence information regarding the entity. 

54. The computer program product of claim 51 wherein fonvarding the 
presence information to an end user includes forwarding a presence 
protocol message to the end user. 

55. The computer program product of claim 54 wherein fonrt^arding a 
30 presence protocol message includes fon^^arding a notify message to 

the end user. 
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57. 

5 

58. 

10 

59. 

15 60. 



The computer program product of claim 51 wherein receiving an IP 
message includes receiving a session initiation protocol (SIP) 
message. 

The computer program product of claim 51 wherein receiving an IP 
message includes receiving an instant messaging and presence 
protocol (IMPP) message. 

The computer program product of claim 51 wherein obtaining the 
presence information from the presence database includes obtaining 
the presence infonnation from a presence database, located internal 
to the presence registration and routing node. 
The computer program product of claim 51 wherein obtaining the 
presence information from the presence database includes obtaining 
the presence information from a presence database located external 
to the presence registration and routing node. 
The computer program product of claim 51 comprising generating an 
accounting message in response to at least one of the IP message 
and the query and fonvarding the accounting message to an 
accounting and billing subsystem. 
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